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ABSTRACT 

Astronomy began as a visual science, first through careful observations of the sky using either 
an eyepiece or the naked eye, then on to the preservation of those images with photographic 
media and finally the digital encoding of that information via CCDs. This last step has enabled 
astronomy to move into a fully automated era - where data is recorded, analyzed and interpreted 
often without any direct visual inspection. Sky in Google Earth completes that circle by providing 
an intuitive visual interface to some of the largest astronomical imaging surveys covering the full 
sky. By streaming imagery, catalogs, time domain data, and ancillary information directly to a 
user, Sky can provide the general public as well as professional and amateur astronomers alike with 
a wealth of information for use in education and research. We provide here a brief introduction 
to Sky in Google Earth, focusing on its extensible environment, how it may be integrated into the 
research process and how it can bring astronomical research to a broader community. With an 
open interface available on Linux, Mac OS X and Windows, applications developed within Sky 
are accessible not just within the Google framework but through any visual browser that supports 
the Keyhole Markup Language. We present Sky as the embodiment of a virtual telescope. 

Subject headings: Astrophysical Data, Data Analysis and Techniques, Tutorials 



1. Introduction 

The purpose of this paper is to provide an in- 
troduction to Sky in Google Eartrfj]- describing 
the data used in its creation, why certain features 
appear the way they do and, most importantly, 
how astronomers can use Sky to create, explore, 
and share their data with a broad community. We 
will generally avoid technical details about the un- 
derlying mechanisms for serving the imagery and 
instead focus on the operations required to place 
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catalogs, images and educational tools within Sky 
and how to serve these data sets efficiently across 
the web. This paper should be viewed as a start- 
ing point for the reader's interaction with Sky and 
the beginning of a discussion about what can be 
accomplished with this new tool. 

Astronomical data is deceptively complex. At 
first glance, it is merely the result of pointing a 
telescope at the sky and recording what you see. 
In reality, however, a scientifically useful descrip- 
tion of a single observation requires knowledge of 
when it was taken, from where, over what wave- 
lengths, in what conditions, covering what area, 
and so on. Combined, the underlying images and 
associated meta-data provide a data set that is not 
just esthetically pleasing but is also scientifically 
meaningful. The goal of Sky is to create a gen- 



eral framework that will enable users to access im- 
ages, catalogs and any associated meta-data across 



Sky there are three primary imagery sources: the 



Digitized Sky Survey (DSS; McLean et al. (2000)), 



the full sky in a seamless manner (Szalay & Gray 



2001). It will serve optical, infrared, x-rays, ultra- 



violet and radio images, enable overlays of these 
images (with transparency) , catalogs and ancillary 
data associated with the underlying images, static, 
time- varying and transient data. In short, it can 
deliver a view of the night sky across the full elec- 
tromagnetic spectrum to a user in an efficient and 
scalable manner. 

2. Design 

Before discussing how to add your own data to 
Sky, we begin with a description of the two princi- 
pal components of Sky: the basemap and the over- 
lays. The first is simply the set of images laid out 
on the celestial sphere to match their positions 
on the sky. The second is the collection of lines, 
placemarks, and images that can be overlaid on 
the base imagery and the annotations associated 
with the basic visual data. Below we will describe 
the contents of both pieces, along with some dis- 
cussion of the design decisions that went into their 
development . 

2.1. Imagery 

The core of Google Earth is a huge RGB color 
image pyramid projected on a sphere, served via 
the internet by Google, with client software that 
runs on each user's computer. This client takes 
advantage of graphics hardware in their computer 
to display a window into the huge image database 
with real time, continuous panning and zooming. 
Data is stored and served in such a way that redis- 
play is as smooth as possible, giving the user the 
illusion that the full detail of all the images is res- 
ident locally on their computer when, in fact, only 
a small portion of it is cached there. Earth was 
created for imagery of a sphere from the outside, 
but for Sky we reversed that perspective, using 
the same infrastructure to serve images of space 
viewed from inside the celestial sphere. 

As with Google Earth, the basemap in Sky pro- 
vides a full-sphere view of the sky by taking im- 
ages with different resolutions and depths from 
a range of sources, registering them to a com- 
mon coordinate system and rendering them as the 
user's vantage point sweeps across the sky. For 



the Sl oan Digital Sky Survey (SPSS; |York et al. 
( |2000| ) and mages from the Hubble Space Tele- 
scope (HST0 The DSS is derived from plate scans 
of the photographic plates from the Second Palo- 



mar Sky Survey (POSSII; |Reid et al.| fll991| )) and 
the UK Schmidt Southern Sky Survey in the J and 
F passbands. The digitization of the photographic 
plates was undertaken by the Space Telescope Sci- 
ence Institute ( Lasker et al.||1996 l and contains a 
total of 1788 plates in the Northern and Southern 
hemispheres. In the north Galactic cap, the DSS 
images are replaced by data from the Sixth Data 
Release of the Sloan Digital Sky Survey (SDSS), 
which covers ^8000 square degrees and contains 
false color images generated from the g, r, and i 
passbands. Finally, there are 130 high resolution 
images drawn from the Hubble Space Telescope 
which cover some of the most interesting regions 
on the sky. 

The union of these data sets covers the full sky. 
The underlying imagery used in Sky resides in a 
lat/long projection ( |Snyder 1926). This results 



in substantial distortion at the poles even when 
re-projecting onto the sphere. Thus, for regions 
within five degrees of the pole we replace the orig- 
inal images with a lower resolution view of the 
sky derived from the Tycho II catalog (|H0g et al. 



2000). These derived images contain stars to a 
depth of B ~ 12 and each star is represented by 
a Gaussian, scaled and colored based on the star's 
magnitude and B — V color. 

2.2. Data Registration and False Color 
Images 

The underlying projection and registration of 
images in Sky is based on the technology used in 
Google Earth. This provides a mature visualiza- 
tion platform on which to develop Sky, a very large 
user base, a simple but extensible interface and 
a well-defined and on-going support and develop- 
ment mechanism. It does, however, lead to a small 
number of trade-offs - related to the way geospa- 
tial data is served - that were made in the course 
of adapting the system to serve astronomical data. 

The first of these concerns the bounds used for 
geodetic coordinates (GEO), which are different 
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from those used in Equatorial coordinates (EQ). 
The geodetic coordinates range in longitude from 
-180 degrees West to +180 degrees East. Hence, 
there is a simple translation that must be made 
from the latter to the former: 



DEC GE o 



RA EQ - 180° 
DEC EQ 



(1) 



A second issue arises due to the fact that the Earth 
is an oblate spheroid which will be discussed in 

H 

All images to be served through Sky were re- 
projected from their native tangent plane (or 
gnomic) projections onto the aforementioned 
lat/long projection. SDSS images were taken from 
jpeg images in the SDSS archiv^] created as part 
of the standard SDSS reduction pipeline. The 
color of the SDSS images was derived from the g, 
r and i passbands using the color transformation 
proposed by Lupton et al. (2004). HST press re- 



lease images were taken from high resolution TIFF 
images created by the STScI OPO groupj^] For the 
DSS data, no color images were readily available 
that matched the color range of the SDSS data. 
Color images were, therefore, generated from the 
original FITS format images (allowing for the ef- 
fects of differential chromatic abberation) in the 
J and F bands and calibrating the photographic 
plates such that their stellar locus matched that 
of the SDSS data. As with Google Earth, the 
basemap is not static and we anticipate contin- 
ued improvements as we refine our treatment of 
the current imagery and new large-scale datasets 
become available. 

2.3. Overlays and Annotation 

As mentioned above, the built-in overlays pro- 
vide a means to annotate the basemap imagery. 
In its initial release Sky utilizes this functionality 
to provide a simple and intuitive introduction to 
objects that are visible to the general public and 
amateur astronomers. For example, we outline the 
88 IAU constellations (Figure [T]) provide a basic 
introduction to the morphologies of galaxies visi- 
ble on the sky and a description of the stages of 
stellar evolution using examples in the basemap 
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to illustrate these tours. Likewise, each of the 
images from the HST is accompanied by a pop- 
up balloon containing a snippet of the press re- 
lease for that image and links for further informa- 
tion. Finally, we have placed icons on objects from 
the Messier, New General and Yale Bright Star 
catalogs (Figure |2j. These placemarks identify 
the object, provide basic observational data about 
the source (names, positions, distance, colors and 
brightnesses along with links to NED and SIM- 
BAD where appropriate; Figure |3| and, in some 
cases, include a snippet from Wikipedia about 
what is known about that star, star cluster, nebula 
or galaxy. 

In addition to these static layers, we also pro- 
vide a time-based layer which shows the position 
of the Moon and Solar System planets over the 
course of three months' time. The ephemeris data 
was generated using the JPL Horizons interfac^] 
The associated placemarks indicate the distance, 
magnitude and angular extent of each body as a 
function of time, controlled by a slider bar that 
appears in the upper right corner of the window 
when these layers are activated. It is worth noting 
that planets' and the Moon's icons are not scaled 
according to their actual appearance on the sky so 
that they can be more easily distinguished from 
the background stars. The duration of the time 
interval is sufficient to show both prograde and 
retrograde motion in the planetary orbits. 

3. Adding Data to Sky 

While the basemap provides a common refer- 
ence frame and a view of the optical sky, the 
strength of Sky comes from its ability to incor- 
porate and display user generated data (images, 
catalogs, time variable data, tours of the sky) on 
top of the basemap. This wide array of function- 
ality is one the advantages of a mature platform, 
as Earth has been performing similar tasks for the 
GIS community for a number of years. For ex- 
ample, the x-ray flux from a galaxy cluster can 
be displayed on top of the optical galaxies seen in 
the basemap, which can themselves be tagged with 
placemarks containing the survey data for each of 
the member galaxies. Likewise, infrared, ultra- 
violet and radio imaging of a single galaxy can be 
overlaid simultaneously, with the user in complete 
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control of the transparency of each layer. In this 
section, we will discuss the basic tools available for 
incorporating data within Sky, as well as point to 
some examples currently available for download to 
supplement the basic Sky package. 

3.1. Keyhole Markup Language 

Most of the methods for putting data into Sky 
involve some use of Keyhole Markup Language 
(KML). An introduction to the KML schema can 
be found at the Google API documentation sitcj^J 
Like Hyper Text Markup Language (HTML) and 
XML, KML files are composed of tags and at- 
tributes. Each tag describes an entity (such as the 
coordinates for a point on the sky or the bound- 
ing box for an image) and each attribute defines 
parameters associated with that entity. KML files 
can be used to add catalog data with placemarks, 
imagery with overlays, and vector data in the form 
of lines and polygons. As with HTML, the basic 
building blocks can be combined in a variety of 
ways to create data sets as utilitarian or richly 
formatted as the user desires. The KML standard 
also evolves over time, adding features and inter- 
faces based on user feedback and proposed usage 
cases. 

3.2. Placemarks 

The most basic element for displaying data is 
the placemark. This acts as a single push-pin lo- 
cated at a discrete point on the sky, possibly with 
some associated data; indeed, the default icon for 
a placemark is an image of a push-pin. KML al- 
lows users to customize the icon associated with 
a placemark, as well as the information that ap- 
pears in the pop-up balloon when a user clicks on 
the placemark. More advanced features include 
the ability to control when the placemark appears 
and how the camera moves when the user clicks 
on the placemark. For example, the appearance of 
the default catalog data in Sky is tuned to the ob- 
jects' magnitudes. This keeps fainter objects from 
appearing until the user is at a higher zoom level, 
which avoids having the viewer overwhelmed by a 
unmanageable number of placemarks on the sky at 
any given time. Likewise, visibility of placemarks 
can be governed by the region of the sky shown in 
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the viewport at any given time, preventing multi- 
ple catalogs across the full sky from being rendered 
at the same time and improving the efficiency of 
serving the data. 

3.3. Vector Data 

The next stage of sophistication is vector data: 
lines and polygons. These are essentially collec- 
tions of placemarks, with line segments connecting 
them and (in the latter case) a solid color filling 
the enclosed area. In both cases, users can con- 
trol both the color and transparency of the lines 
and polygons. This makes vector data ideal for 
a quick description of a observational footprint or 
uncertainty region associated with a survey or ob- 
servation, as one might have with the observation 
of a gamma ray burst, for example. 

3.4. Image Overlays 

The KML tag name GroundOverlay is inherited 
from Earth, but these are simply images projected 
against the basemap in Sky. GroundOverlays are 
defined by associating an image with some bound- 
ing region on the sky, the latter being given by the 
bounds in the four cardinal directions and a rota- 
tion angle. For small-area images, the difference 
between the tangent plane and lat/long projec- 
tion is slight enough that images can be aligned 
to the basemap using only a linear transforma- 
tion. Google Earth has a graphical interface for 
aligning images this 

Larger images (or those nearer the poles) can be 
more difficult. As mentioned previously, since Sky 
shares a rendering engine with Earth, the geome- 
try of the sky is, in fact, a slightly oblate spheroid 
(technically, the WGS84 projection). The GIS 
community has developed a number of tools for 
handling re-projections of images using this ge- 
ometry, most notably the Geospatial Data Ab- 
straction Library (GDAL). This software can warp 
images from one projection (including a tangent 
plane) to another and encodes the geometric in- 
formation necessary for registering the image on 
the sphere in either an image header (analogous 
to a FITS header) or an associated "world file" , 
depending on the image format. While users may 
want to become more familiar with the GDAL 
software themselves, we provide a simple, open 
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source tool wcs^fcmfj which will read in an image 
in a variety of formats and WCS information from 
a FITS header and generate a properly warped im- 
age and overlay KML for you. This tool is avail- 
able in both Python and C++ versions. 

3.5. Network Links and Regionation 

While the basic elements of KML are static, 
network links allow users to load new KML dy- 
namically. This may be triggered by a change in 
the view of the camera in Sky or after a speci- 
fied interval has elapsed. This flexibility allows 
for a limitless number of applications: updating 
the location of satellites in orbit or their current 
observing target, displaying feeds from gamma ray 
burst trackers, providing real-time updating of ob- 
servations to collaborators back home, and so on. 
Likewise, the ability to have network links acti- 
vated based on the viewport of the sky gives KML 
authors the ability to regionate their data. 

Regionation is simply splitting a given data set 
into a hierarchical structure, similar to what hap- 
pens with the imagery and placemarks that are 
part of the basic Sky data set. When the camera 
is far from the surface of the celestial sphere, the 
imagery served is at a very low resolution (finer 
details would be lost anyway, so displaying them 
is unnecessary) and only the brightest stars and 
galaxies are annotated to avoid overwhelming the 
user. As the camera zooms in, higher resolution 
imagery is fetched automatically and fainter ob- 
jects are tagged. The same can be accomplished 
with network links to other files that are tied to 
progressively smaller regions on the sky. This al- 
lows vast amounts of catalog data and high resolu- 
tion imagery to be displayed progressively on de- 
mand, instead of clogging the user's internet con- 
nection all at once. Regionato^ an open source 
Python program, provides a simple interface for 
regionating KML files that have already been cre- 
ated (like those produced by the Python version 
of wcs2kml, for example). The C++ version of 
wcs2kml includes a feature which will regionate 
its outputs as well, producing a hierarchical set 
of network linked KML files and sub-sampled ver- 
sions of astronomical images with associated WCS 
information. For large mosaics (or even images 
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taken with large format CCDs) , this can vastly im- 
prove the performance of the resulting image over- 
lay. The wcs2kml package also includes utilities for 
converting FITS catalog data to KML placemarks 
and regionating them as well. 

3.6. Sharing &: Publishing Data 

Since KML is completely platform independent, 
data sharing is easy. Simply construct a KML file 
describing your data and email it to your collab- 
orator. Even better, place it on a webpage where 
it can be discovered and shared with the world. 
Larger KML files (which are fundamentally just 
simple ASCII text files) can be compressed into a 
zip archive (generally tagged with a ".kmz" suf- 
fix to differentiate them from uncompressed files) 
along with imagery to form a self-contained file 
that can be opened natively by Sky. Alternatively, 
imagery can be loaded with URL pointers, just like 
in standard HTML. 

3.7. Working with KML in Sky mode 

KML was created to annotate Google Earth 
with images, placemarks and ancillary informa- 
tion. As the KML schema is designed to support 
this Earth-centric annotation some of the features 
and tags present within KML do not translate nat- 
urally to annotation of the sky. We provide here a 
brief overview of these tags and features and pro- 
vide workarounds for their use in Sky. 

To differentiate between KML for viewing on 
the Sky as opposed to on Earth a hint attribute 
is available within the initial specification of the 
KML schema. Adding the Sky hint[^]to your <kml> 
tag will cause the client to prompt a user to open 
the KML under sky mode (if the view is currently 
Earth-based) . All KML saved from within the 
Google Earth client while it is in Sky mode will 
have this attribute set by default. 

Placemarks, image overlays, lines, polygons and 
styles are all supported under Sky. Tilt and roll 
angle for the camera position are ignored when 
viewing images and placemarks under Sky as the 
current astronomical imagery is a simple projec- 
tion onto a sphere without altitudinal information. 
Range for the Look At and other positional tags 
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(i.e. the altitude above the Earth that the camera 
zooms to when a placemark is double-clicked) are 
measured in meters. To convert to an angular sys- 
tem that is more appropriate for viewing the sky 
we suggest the following relation, 

R sin(a/2 - 13/2) = (R -r) sin(a/2) (2) 

where r is the range to use in the LookAt tag, R 
is the radius of the Earth (6371 km) , a is the an- 
gle subtended by the viewer when you are viewing 
from the maximum distance from the sky (i.e. you 
are pulled all the way back to the center of the 
Earth; for the current client a = 80°) and (3 is the 
angular diameter of your region. For r«ii, this 
reduces to, 

P = 2rtan(a/2)/i? (3) 

where f3 is in radians. 

Images that are incorporated into Sky are cor- 
rectly oriented (i.e. East to the left) and do not 
require any transformations other than rotation. 
Rotation in Sky is in the clockwise direction (op- 
posite from that in Earth mode). 3D sketchup 
models for objects within Sky are not officially sup- 
ported but may work. 

4. Future 

The research applications of Sky are limitless. 
Data can be visualized from an all-sky view all the 
way to native resolution of the underlying imagery 
with minimal pre-processing. Catalog data can 
be immediately placed on the sky imagery with 
KML placemarks enabling new discoveries to be 
made available in almost real time. Data can be 
shared within a research group or to the broader 
community securely by simply sending KML files 
or posting them on a webserver. Finding charts 
are as simple to create as producing a screenshot 
or zooming to a location just prior to observing. 
Survey progress can be visualized in real time by 
updating KML available over the internet (via net- 
work links) as images come off the CCDs. Finally, 
when the observations are ready to be made pub- 
lic, Sky is an ideal platform to reach parts of the 
general public interested in astronomy and put 
your results in the context of the broader astro- 
physical data universe. 

As a tool with a simple, extensible and intuitive 
interface we see Sky in Google Earth as the embod- 



iment of a Virtual Telescope, providing open ac- 
cess to data through open standards. It leverages 
the power of the Google infrastructure for serving 
data to a wide range of people while also enabling 
any user to integrate and share their own images 
and catalogs. We hope that this step towards the 
democratization of science will enable a new era 
of visual discovery and science communication. 

The authors wish to thank Chikai Ohazama, 
Lior Ron, Effie Seiberg, Steve Zelinka, Andrew 
Moore, Robert Pike, Brian McClendon, Linne Ha, 
Mohammad Khan, Brian McClean, Dylan Myers, 
Wei Luo, Peter Birch, Andrew Kirmse, Michael 
Ashbridge, Bent Hagemark, Chris DiBona, Sam 
Roweis, and Keir Mierle for their tireless efforts to 
make Sky what it is and what it will be. 

Please see the Sky partners homepage^ for a 
list of the institutions contributing imagery to Sky. 
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Fig. 1. — Large scale image of the sky showing constellations and Messier (red) and NGC (blue) object 
tags. The basemap imagery is largely dark thanks to the re-sampling of the DSS and SDSS imagery to lower 
resolution, although a number of stars are visible at the junctions of the constellation lines. Icons are also 
available for objects in the Yale Bright Star catalog, although they are deactivated in the current image. 
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Fig. 2. — Closer view of the imagery for the area of sky around M101. As the credits at the lower middle 
of the image indicate, this imagery is a combination of data from the SDSS and the HST, with the latter 
providing a higher resolution mosaic of the central galaxy region. The icon at the top of the M101 HST 
imagery contains information related to the press release issued by the STScI for this image, as well as links 
to associated papers and observational data. 
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Fig. 3. — Same as Figure [2j but with the information balloon for one of the NGC objects opened. These 
balloons contain basic observational data as well as links to the NED and Simbad databases for further 
information and a snippet of Wikipedia text for each object, if available. This particular balloon, chosen so 
as not to obscure the imagery, shows the bare minimum of information available for a given object. 
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